iT邦幫忙

2024 iThome 鐵人賽

DAY 10
1
Modern Web

後端菜雞仔想學 Laravel系列 第 10

Controller & Route:來指派店長跟分配店員吧!

  • 分享至 

  • xImage
  •  

在前天 Laravel 的 MVC 架構設計模式 文章裡有提到:Controller(控制器)是負責處理請求,並根據需求來決定使用哪個 Model 或 View。

我的理解

Controller 就像是一家商店的店長,負責掌控整個店的運作。

當客人(使用者)透過 Route(門口的店員)進入商店,店員會根據客人的需求引導他們到不同的區域(也就是不同的功能)。

店長(Controller)接到指令後,可能會去找 Model(像是倉庫管理員)拿商品資料,也可能會請 View(像是商品陳列設計師)準備好展示櫃或商品頁面,把拿到的資料「擺設」得漂漂亮亮的,提供給客人瀏覽。

如果需要的話,店長還可能會處理一些外部服務,像是請外面的金流公司來幫忙結帳。

簡單來說,Controller 的工作就是要協調所有部門,確保整個流程順暢,讓客人有個良好的購物體驗。

小食譜04:實現 API

指派店長:建立 Controller

我之前在 Laravel 專案中建立一個名為 Product 的 Model,並同時「載入預設CRUD方法」建立以下檔案:

  • Migration
  • Controller

因為載入預設CRUD方法,所以打開 ProductController.php 可以看到已經有很多方法寫在裡面,對應到資料庫的 CRUD 操作。

「ProductController」就是我指派的店長。

店長建立不同區域的工作流程

官方文件:Actions Handled by Resource Controllers

Verb URI Action Route Name
GET /photos index photos.index
GET /photos/create create photos.create
POST /photos store photos.store
GET /photos/{photo} show photos.show
GET /photos/{photo}/edit edit photos.edit
PUT/PATCH /photos/{photo} update photos.update
DELETE /photos/{photo} destroy photos.destroy

「線上產品瀏覽系統」不同區域的工作流程

Method URI Name Action
POST api/products/ product.store App\Http\Controllers\ProductController@store
GET api/products/ product.index App\Http\Controllers\ProductController@index
GET api/products/{product} product.show App\Http\Controllers\ProductController@show
PATCH api/products/{product} product.update App\Http\Controllers\ProductController@update
DELETE api/products/{product} product.destroy App\Http\Controllers\ProductController@destroy

範例

新增產品:[ POST ] api/products/ 對應到的是 ProductController 的 store 方法。

ProductController.php

use Illuminate\Http\Response;

public function store(Request $request)
    {
        $product = Product::create($request->all());
        return response()->json($product, Response::HTTP_CREATED);
    }

分配店員:路由設定

店長可以將引導工作分配給很多店員,也可以分配給一位自帶分身術的店員承攬所有引導工作。
「routes」目錄就是我們分配店員的地方,而我們這裡要分配的是「api.php」類型的店員。

web.php 跟 api.php 的差別

在 Laravel 中,路由檔案通常會分成兩大類:web.php 和 api.php。

  • web.php:專門用來定義網站或 Web 應用程式的路由,主要處理跟使用者介面相關的部分,也就是當使用者透過瀏覽器進入網站時要用的路徑。
  • api.php:用來設定 API 的路由,通常是服務 AJAX 請求,或者是當其他應用程式需要跟你的系統互相溝通時用到的接口,這裡主要會處理 JSON 或 XML 格式的資料。

在之前 初步了解 Laravel 目錄結構 文章裡有提到 Laravel 11 有大改動,所以建立 Laravel 新專案後,是沒有 api.php 檔案的,需要使用 artisan 指令新增:

php artisan install:api

新增後打開 api.php

我要分配給一位自帶分身術的店員,承攬所有引導工作。
就是 Laravel 的內建方法:apiResource
可以把 URI 自動對應到 ProductController 內相對應的方法。

參考官方文件:API Resource Routes

api.php 路由設定使用 apiResource 會自動對應

<?php

use App\Http\Controllers\ProductController;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Route;

Route::apiResource('products', ProductController::class);

接著打開 Product.php

可以在 Model 使用 $fillable 屬性,指定哪些欄位可以 Mass Assignment
這樣後續可以練習產生假資料去測試系統。

參考文章:laravel 中模型中 $fillable 的用法

Product.php

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Database\Eloquent\Model;

class Product extends Model
{
    use HasFactory;

    protected $fillale = [
        'type_id',
        'product_name',
        'product_description',
        'price',
    ];
}

避免使用 $fillable 的情況

使用 $fillable 的主要目的是為了防止將不應該被修改的資料寫入,同時也能方便地大量賦值給指定的資料。
但如果在專案中允許使用 $fillable,有可能會發生一些風險,例如:有人不小心把敏感欄位放進 $fillable 陣列裡,這樣就可能造成安全問題。

所以,對於涉及會員權限、財務資料等比較敏感的專案,建議不使用 mass assignment。雖然這樣寫的程式碼會比較長,但透過手動賦值的方式,可以更精準地控制需要賦值的資料,避免潛在的風險,讓資料安全性更高。

簡單來說,安全第一!在敏感資料的處理上,還是建議採取更謹慎的方式。


上一篇
Migration & 資料庫設計
下一篇
測試 API:初次使用也能快速上手的 Postman
系列文
後端菜雞仔想學 Laravel13
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言